home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
The CICA Windows Explosion!
/
The CICA Windows Explosion! - Disc 2.iso
/
nt
/
ntkb.zip
/
NTKB.EXE
/
Q103
/
7
/
65.TXT
< prev
Wrap
Text File
|
1993-09-13
|
4KB
|
82 lines
DOCUMENT:Q103765 10-SEP-1993 [W_NT]
TITLE :#NOFNR Flag in LMHosts to Communicate Across Routers
PRODUCT :Windows NT
PROD/VER:3.10
OPER/SYS:WINDOWS
KEYWORDS:
--------------------------------------------------------------------
The information in this article applies to:
- Microsoft Windows NT operating system version 3.1
- Microsoft Windows NT Advanced Server version 3.1
--------------------------------------------------------------------
SUMMARY
=======
Some of the LAN Manager for UNIX and Pathworks servers may have problems
in communicating across routers with Windows NT workstations. The use of
#NOFNR flag in the LMHosts file solves the problem.
MORE INFORMATION
================
When you are communicating with a server across a router in a IP
routed environment, the LMHost file is used to resolve Workstation
name-to-IP address mapping. The LMHost entry for a remote machine name
provides the IP address for the remote machine. In Lan Manager 2.x,
providing the LMHosts entry eliminates the need to do a Name Query
broadcast to the local domain and instead a TCP session is established
with the remote machine. Windows NT performs the same function in a
different way.
When an LMHosts entry exists for a remote server, Windows NT will not
send a Name Query broadcast to the local subnet and instead send a
directed Name Query to the remote server. If the remote server does
not respond to the Name Query, further communications (TCP SYN, and so
on) will not take place. This was done to eliminate the performance
issues when trying to connect to a remote machine when it was not
available (down).
Some of the older LAN Manager for UNIX and DEC Pathworks servers do not
respond to directed Name Queries sent by Windows NT. In that case, the
users will see an error 53 (Path not found), even though they have
specified the LMHosts entries correctly. A new LMHosts flag #NOFNR was
added to solve this problem. By specifying the #NOFNR flag on the same
line where the name resolution information for the server is provided,
the directed Name Query can be avoided. For example:
130.20.1.1 mylmxserver #PRE #NOFNR
Note that this will only apply to mylmxserver and not to any other
entries in the LMHosts file. To set a global flag, an entry could be
added in the registry. To completely remove any directed Name Queries
sent from a Windows NT machine, create the following value in
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Nbt\Parameters:
NoDirectedFNR REG_DWORD 1
This will cause the directed Name Queries to not go out for any remote
machines.
Additional reference words: 3.10 Tcpip lmhosts Findname
KBCategory:
KBSubCategory: tcip
=============================================================================
THE INFORMATION PROVIDED IN THE MICROSOFT KNOWLEDGE BASE IS
PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND. MICROSOFT DISCLAIMS
ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES
OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. IN NO
EVENT SHALL MICROSOFT CORPORATION OR ITS SUPPLIERS BE LIABLE FOR
ANY DAMAGES WHATSOEVER INCLUDING DIRECT, INDIRECT, INCIDENTAL,
CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF
MICROSOFT CORPORATION OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE
POSSIBILITY OF SUCH DAMAGES. SOME STATES DO NOT ALLOW THE EXCLUSION
OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES
SO THE FOREGOING LIMITATION MAY NOT APPLY.
Copyright Microsoft Corporation 1993.